IRIX Base Documentation 2002 November/SGI IRIX Base Documentation 2002 November.iso/usr/share/catman/a_man/cat7/input.z/input

Text File | 2002-10-03 | 21.1 KB | 463 lines

IIIINNNNPPPPUUUUTTTT((((7777))))                                                              IIIINNNNPPPPUUUUTTTT((((7777))))



NNNNAAAAMMMMEEEE
     input - input devices

DDDDEEEESSSSCCCCRRRRIIIIPPPPTTTTIIIIOOOONNNN
     The IRIX operating system includes support for a number of input devices,
     and support for additional devices can be added.

     Standard input devices include the keyboard and mouse.  Installing the
     "Optional Input Devices" (eoe.sw.optinput) software adds support for the
     following optional input devices:

     ++++oooo    Calcomp tablets. (Module Name: _c_a_l_c_o_m_p, X Name: _t_a_b_l_e_t)

     ++++oooo    Hitachi HDG-J tablets. (Module Name: _h_i_t_a_c_h_i, X Name: _h_i_t_a_c_h_i)

     ++++oooo    Other Hitachi tablets. (Module Name: _t_a_b_l_e_t, X Name: _t_a_b_l_e_t)

     ++++oooo    Wacom tablets. (Module Name: _w_a_c_o_m, X Name: _w_a_c_o_m)

     ++++oooo    The dial box. (Module Name: _d_i_a_l_b_o_x, X Name: _d_i_a_l_b_o_x)

     ++++oooo    The dial and button box combination. (Module Name: _d_i_a_l, X Name:
          _d_i_a_l+_b_u_t_t_o_n_s)

     ++++oooo    Imp infra-red presentation mouse. (Module Name: _i_m_p, X Name: _i_m_p)

     ++++oooo    Logitech Magellan 3D controller. (Module Name: _m_a_g_e_l_l_a_n, X Name:
          _m_a_g_e_l_l_a_n)

     ++++oooo    Space ball. (Module Name: _s_b_a_l_l, X Name: _s_p_a_c_e_b_a_l_l)

     Application programs access these devices using the X Input Extension.

     The drivers for these devices are implemented as loadable STREAMS modules
     (see _m_l(_1_m)).  They handle device initialization and generate input
     events in response to input from the devices.  A driver will only be
     loaded into the kernel when the corresponding device is opened for use.

   CCCCOOOONNNNFFFFIIIIGGGGUUUURRRRIIIINNNNGGGG AAAA DDDDEEEEVVVVIIIICCCCEEEE FFFFOOOORRRR UUUUSSSSEEEE
     The easiest way to set up an optional input device is to use the visual
     system adminstration tool _S_e_r_i_a_l_D_e_v_i_c_e_M_a_n_a_g_e_r(_1_m) which is normally
     accessed via the _T_o_o_l_c_h_e_s_t(_1)'_s SSSSyyyysssstttteeeemmmm section, through the System
     Manager tool.

     The X server looks for input devices by scanning the directory
     ////ddddeeeevvvv////iiiinnnnppppuuuutttt.  Instead of using the _S_e_r_i_a_l_D_e_v_i_c_e_M_a_n_a_g_e_r(_1_m), you can create
     a link in this directory to the device special file associated with the
     serial port the device is connected to.  The name of the link must be the
     same as the streams module name for the desired input device.






                                                                        PPPPaaaaggggeeee 1111






IIIINNNNPPPPUUUUTTTT((((7777))))                                                              IIIINNNNPPPPUUUUTTTT((((7777))))



     Note that the _S_e_r_i_a_l_D_e_v_i_c_e_M_a_n_a_g_e_r will check various configuration files
     and force you to remove other devices configured on a port before
     allowing you to assign an input device to it.  If you create the input
     device file yourself, you must ensure that no other devices or programs
     are associated with the port in question.

   CCCCUUUUSSSSTTTTOOOOMMMM IIIINNNNPPPPUUUUTTTT DDDDEEEEVVVVIIIICCCCEEEESSSS
     Support for custom X input devices can be added.  First a STREAMS module
     for the device must be written; the subsystem x_dev.src.examples installs
     sample driver code in /_u_s_r/_s_h_a_r_e/_s_r_c/_X/_i_n_p_u_t/_d_r_i_v_e_r_s. The device can then
     be configured to work with the _S_e_r_i_a_l_D_e_v_i_c_e_M_a_n_a_g_e_r by performing the
     following actions.

     An _f_t_r file (see _f_f_t_r(1)) for the device must be created in
     /_u_s_r/_l_i_b/_f_i_l_e_t_y_p_e/_v_a_d_m_i_n/_p_o_r_t_s.  For example, an ftr file for the dial
     and button box might appear as follows:

          TYPE DialAndButton
               MATCH       false;
               LEGEND      DialAndButton
               ICON {
                    include("iconlib/DialAndButton.fti");
               }

     "DialAndButton" should be replaced with a unique type name for the
     device.  The icon description may be included from the
     /_u_s_r/_l_i_b/_f_i_l_e_t_y_p_e/_v_a_d_m_i_n/_p_o_r_t_s/_i_c_o_n_l_i_b directory, as shown.  After this
     file is created, the following commands must be executed:

          % cd /usr/lib/filetype
          % make

     A file must also be created in the /_u_s_r/_l_i_b/_X_1_1/_i_n_p_u_t/_i_n_s_t_a_l_l_e_d
     directory.  This file must have the same name as the streams module for
     the device.  The first line in this file should be the string which will
     identify the device for the user.  The second line should be the type
     name as given in the ftr file.  Blank lines and lines that begin with the
     character '#' are ignored.

     For example, the file for the dial and button device might appear as
     follows:

          # Icon label
          Dials & Buttons

          # Icon type
          DialAndButton

   DDDDEEEEVVVVIIIICCCCEEEE CCCCOOOONNNNTTTTRRRROOOOLLLLSSSS
     Device controls form an extensible mechanism for changing or querying
     device characteristics.  They fall into two categories:  those
     intercepted by the X server (_x__i_n_i_t controls) and those handled by the



                                                                        PPPPaaaaggggeeee 2222






IIIINNNNPPPPUUUUTTTT((((7777))))                                                              IIIINNNNPPPPUUUUTTTT((((7777))))



     device drivers (_d_e_v_i_c_e__i_n_i_t controls).  The X server handles the _x__i_n_i_t
     controls, which change the way the server views devices.  The device
     drivers handle the _d_e_v_i_c_e__i_n_i_t controls, which change device
     characteristics.

     Device controls can be permanently configured by storing them in files
     which reside in the directory ////uuuussssrrrr////lllliiiibbbb////XXXX11111111////iiiinnnnppppuuuutttt////ccccoooonnnnffffiiiigggg.

     The _d_e_v_i_c_e__i_n_i_t controls must be placed in a file with the same name as
     the streams module for the device (which is also the name of the link
     created in /_d_e_v/_i_n_p_u_t).  The format is as follows:

          device_init {
               control "argument"
               control "argument"
               ...
          }

     The _x__i_n_i_t controls must be placed in a file with the X name of the
     device (as supplied by the streams module).  The format is as follows:

          x_init {
               control "argument"
               control "argument"
               ...
          }

     If the streams module name and the X name are the same, _d_e_v_i_c_e__i_n_i_t and
     _x__i_n_i_t controls may be placed in the same file.  The device control
     arguments must be enclosed in quotation marks.

     You can also issue device controls dynamically by calling
     _X_S_G_I_D_e_v_i_c_e_C_o_n_t_r_o_l(_3_X_1_1) from within a program.  The current setting of a
     device control can be queried by using _X_S_G_I_D_e_v_i_c_e_Q_u_e_r_y(_3_X_1_1).

     The sample program _d_e_v_c_t_r_l can be used to issue or query device controls
     from a command line prompt or script.  The source for this program is
     installed in /_u_s_r/_s_h_a_r_e/_s_r_c/_X/_i_n_p_u_t/_c_l_i_e_n_t_s by "X11 Source Code Examples"
     (x_dev.src.examples).

   DDDDEEEEVVVVIIIICCCCEEEE IIIINNNNIIIITTTTIIIIAAAALLLLIIIIZZZZAAAATTTTIIIIOOOONNNN
     The X server looks for new devices both at initialization time and when a
     client requests a list of devices.  When it finds a new device, it:

     ++++oooo    opens the device and loads the streams module

     ++++oooo    issues device_init controls

     ++++oooo    asks the device to describe itself






                                                                        PPPPaaaaggggeeee 3333






IIIINNNNPPPPUUUUTTTT((((7777))))                                                              IIIINNNNPPPPUUUUTTTT((((7777))))



     ++++oooo    issues x_init controls

     ++++oooo    closes the device unless autostart (see below) is on

     When some program opens a device that is not autostarted nor open by some
     other program, the X server:

     ++++oooo    opens the device and loads the streams module

     ++++oooo    issues device_init controls

     ++++oooo    issues x_init controls

     ++++oooo    starts reporting events from the device

   XXXX____IIIINNNNIIIITTTT CCCCOOOONNNNTTTTRRRROOOOLLLLSSSS
     The X server intercepts the following _x__i_n_i_t controls:

     aaaauuuuttttoooossssttttaaaarrrrtttt "on"/"off"
          Specifies whether ("on") or not ("off") the device is opened
          automatically by the X server.  Extension devices are normally
          ignored until some client explicitly opens them, but you can change
          that using this directive.  This allows you to use several devices
          to control the cursor simultaneously without explicitly opening the
          extension devices you wish to use.

     kkkkeeeeyyyymmmmaaaapppp <_k_e_y_m_a_p _n_a_m_e>
          Not implemented, but reserved (and intercepted).

     mmmmoooottttiiiioooonnnnhhhhiiiisssstttt <_e_v_e_n_t _c_o_u_n_t>
          Specifies the maximum number of events to keep in a motion history
          buffer for the device.  This buffer is accessed using the X Input
          Extension request XGetDeviceMotionEvents.  The default size is 0.
          The maximum size is 2048 events.

     nnnnaaaammmmeeee <_n_e_w _n_a_m_e>
          Renames the device.   This changes the name of the device as
          reported by the X Input Extension.

     ppppuuuusssshhhhppppooooiiiinnnntttteeeerrrr "on"/"off"/"exclusive"
          Controls whether or not the device generates core pointer events as
          well as extension events.   "on" means generate both,  "off" means
          generate extension events only and "exclusive" means generate core
          events for two axes and extension events for the rest of them.

     ppppuuuusssshhhhxxxx <_a_x_i_s _n_u_m_b_e_r>
          Specifies the device axis which generates the X position in core
          pointer events if pushpointer is "on" or "exclusive".

     ppppuuuusssshhhhyyyy <_a_x_i_s _n_u_m_b_e_r>
          Specifies the device axis which generates the Y position in core
          pointer events if pushpointer is "on" or "exclusive".



                                                                        PPPPaaaaggggeeee 4444






IIIINNNNPPPPUUUUTTTT((((7777))))                                                              IIIINNNNPPPPUUUUTTTT((((7777))))



     ssssccccaaaalllleeee "iso"/"fit"/"none"
          Tells the X server how to scale the device the next time it is
          opened.   Scale "iso" uses the full range of either the X or Y axis
          but preserves a 1 to 1 aspect ratio. Scale "fit" uses the full range
          of both axes (aspect ratio may be skewed).   Scale "none" uses raw
          device data.   Unless you're supporting a tablet, you probably want
          scale "none".

     ssssccccaaaalllleeeewwwwhhhhiiiicccchhhh "allvals"/"novals"/"ptrvals"/"ptr"/"noptr"/"none"
          Specifies the axes and events affected by the ssssccccaaaalllleeee control.
          Scalewhich "allvals" scales all extension device valuators
          (meaningless for scale-to-fit). Scalewhich "novals" doesn't scale
          any extension device valuators.   Scalewhich "ptrvals" scales only
          the extension valuators which correspond to the core pointer X and Y
          axes.    Scalewhich "ptr" means to scale the core pointer X and Y
          values and "noptr" means no to.   Scalewhich "none" means don't
          scale anything.  The effects of this control are cumulative, so you
          can issue several.

     ssssccccrrrreeeeeeeennnncccchhhhaaaannnnggggeeee "on"/"off"
          For configurations where multiple screens are associated with a
          single X server, specifies whether a change to a different screen
          can be triggered by the device.  The default is "on" (screen changes
          enabled) for all devices.  The device must be an active pointer
          device (pushpointer "on" or "exclusive") in order to trigger a
          screen change.

     ttttyyyyppppeeee <_n_e_w _t_y_p_e>
          Changes the type of the device as reported by the X Input Extension.

   DDDDEEEEVVVVIIIICCCCEEEE____IIIINNNNIIIITTTT CCCCOOOONNNNTTTTRRRROOOOLLLLSSSS
     Here are some of the more common _d_e_v_i_c_e__i_n_i_t controls.  Any control which
     changes the observed characteristics of the device should be issued only
     as a _d_e_v_i_c_e__i_n_i_t control because the X server has already asked the
     device to describe itself when it issues the _x__i_n_i_t controls and it will
     not notice the changes.  "Observed chararcteristics" include number of
     axes, buttons or keys or the range of the devices axes; they do nnnnooootttt
     include controls which change the way that physical device events are
     mapped onto X events.

     pppprrrreeeessssssssuuuurrrreeee "on"/"off"
          For pressure sensitive tablets.   Start/stop reporting pressure (and
          tilt/height in some cases) information.  This option adds axes (for
          the pen pressure value) to a device, so it should be a _d_e_v_i_c_e__i_n_i_t
          option.

     bbbbttttnnnnpppprrrreeeessssssssuuuurrrreeee <_p_r_e_s_s_u_r_e>
          For pressure sensitive tablets.  Specifies the threshold above which
          the tip pressure generates a button event.  Note that this is a raw
          8 bit integer, *not* an ascii decimal number.  To set the tip button
          pressure to '5', use '^E' (control-E), NOT '5'.  This option
          controls the mapping of physical pressure events on to X button



                                                                        PPPPaaaaggggeeee 5555






IIIINNNNPPPPUUUUTTTT((((7777))))                                                              IIIINNNNPPPPUUUUTTTT((((7777))))



          events, but it does nnnnooootttt affect the observed characteristics of the
          device.  It can safely be used as either an _x__i_n_i_t or a _d_e_v_i_c_e__i_n_i_t
          option.

     iiiinnnnvvvveeeerrrrtttt <_a_x_e_s _t_o _i_n_v_e_r_t>
          Where <axes to invert> is a (case sensitive) string of characters
          which specifies the axes to be inverted.  An 'x' means invert the X
          axis in core pointer events, a 'y' means invert the Y axis.  A
          single digit '0'-'9' means invert the corresponding axis in
          extension events.   A '!' in the string reverses the interpretation
          of all following characters in the string.   For example "y1" means:
          invert the Y axis in core events and axis 1 in extension events
          (leave all other axes alone).   A "y!x" means: invert the Y axis in
          core events but do not invert the X axis; in this case, extension
          events are not affected.  Affects mapping only, so it can be either
          _x__i_n_i_t or _d_e_v_i_c_e__i_n_i_t.

     lllleeeefffftttt////rrrriiiigggghhhhtttt////ttttoooopppp////bbbboooottttttttoooommmm <_o_f_f_s_e_t>
          Primarily for tablet devices.  Specifies a dead margin (in raw
          device coordinates) around the edges of the tablet.  These requests
          change the apparent size of the tablet surface so they should be
          device_init options only.

     mmmmaaaaxxxx[[[[xxxxXXXXyyyyYYYY0000----9999]]]] <_m_a_x_i_m_u_m _v_a_l_u_e>
          Changes the maximum value for the corresponding valuators.   Note
          that "maxx" and "maxy" change the axes that correspond to the core
          pointer axes, not the core pointer events themselves.   In other
          words, you can't use this request to get illegal core pointer events
          (core pointer events are always restricted to the screen).
          _d_e_v_i_c_e__i_n_i_t only.

     mmmmooooddddeeeellll <_v_e_n_d_o_r _s_p_e_c_i_f_i_c>
          Specifies the model of the device so the driver can do model
          specific things.   Unfortunately, probing a device from the kernel
          is pretty messy, so we use this control in a configuration file to
          specify the type of device attached (for now).  _d_e_v_i_c_e__i_n_i_t only.

     ssssccccaaaalllleeee[[[[xxxxXXXXyyyyYYYY0000----9999]]]] <_s_c_a_l_e _f_a_c_t_o_r>
          Control scaling on an axis by axis basis.  To use this, first set
          scalewhich _n_o_n_e in the X server so the X server doesn't clobber your
          values.  For example:

          scalex "1/5"
               scales core pointer x events by one fifth.

          scale4 "5"
               scales extension valuator 4 events by 5.

          Note that changing scaling does not affect the range of the valuator
          - extension valuators are clamped to the range of the device.   In
          other words, if you scale a tablet axis by 5, you'll only be able to
          use one-fifth of the tablets surface in the corresponding direction.



                                                                        PPPPaaaaggggeeee 6666






IIIINNNNPPPPUUUUTTTT((((7777))))                                                              IIIINNNNPPPPUUUUTTTT((((7777))))



          These affect mapping only, so they can be _d_e_v_i_c_e__i_n_i_t or _x__i_n_i_t.

EEEEXXXXAAAAMMMMPPPPLLLLEEEESSSS
     The calcomp tablet uses a streams module named "calcomp" but reports an X
     name of "tablet".  The Drawing Pad II is 7" by 7" and has a resolution of
     1000 points per inch.  To scale raw tablet events to screen coordinates
     (1280x1024) we create /usr/lib/X11/input/config/tablet (name of X device)
     with the contents:

     x_init {
         scalewhich  "none"
         scalex      "914/5000"
         scaley      "914/5000"
         scale0      "914/5000"
         scale1      "914/5000"
     }


     To make the calcomp tablet control the cursor automatically, we would add
     the lines:

     pushpointer    "on"
     autostart      "on"


     If we wanted a 1" margin around the tablet, we'd create a device_init
     file (/usr/lib/X11/input/config/calcomp) with the contents:

     device_init {
         left        "1000"
         right       "1000"
         top         "1000"
         bottom      "1000"
     }


     Of course, this reduces the tablet surface by 2000 units in each
     direction, so we'd have to recalculate scale[xy01] values for the x_init
     options to get the mapping right.

     If we wanted to do the same thing for the Hitachi tablet, (streams module
     == tablet, X name == tablet) we'd put both the x_init and device_init
     sections in the same file (/usr/lib/X11/input/config/tablet).

FFFFIIIILLLLEEEESSSS
     /dev/input/*
     /usr/lib/X11/input/config/*

SSSSEEEEEEEE AAAALLLLSSSSOOOO
     SerialDeviceManager(1m), sysmgr(1m), mknod(1m), ml(1m),
     XSGIDeviceControl(3X11), XSGIDeviceQuery(3X11), imp(7), hitachi(7)




                                                                        PPPPaaaaggggeeee 7777